[Enter a brief description of the target-of-test (components, application, system, etc.) and its goals.á Include information such as major functions and features, its architecture, and a brief history of the project.á This section should only be about three to five paragraphs.]

1.3 Scope

[Describe the stages of testing¡╛for example, Unit, Integration, or System╛and the types of testing that will be addressed by this plan, such as Function or Performance.

Provide a brief list of the target-of-testÆs features and functions that will or will not be tested.

List any assumptions made during the development of this document that may impact the design, development or implementation of testing.

List any risks or contingencies that may affect the design, development or implementation of testing.

List any constraints that may affect the design, development or implementation of testing]

1.4 Project Identification

The table below identifies the documentation and availability used for developing the test plan:

[Note:á Delete or add items as appropriate.]

Document (and version / date)	Created or Available	Received or Reviewed	Author or Resource	Notes
Requirements Specification	o Yesá o No	o Yesá o No
Functional Specification	o Yesá o No	o Yesá o No
Use-Case Reports	o Yesá o No	o Yesá o No
Project Plan	o Yesá o No	o Yesá o No
Design Specifications	o Yesá o No	o Yesá o No
Prototype	o Yesá o No	o Yesá o No
UserÆs Manuals	o Yesá o No	o Yesá o No
Business Model or Flow	o Yesá o No	o Yesá o No
Data Model or Flow	o Yesá o No	o Yesá o No
Business Functions and Rules	o Yesá o No	o Yesá o No
Project or Business Risk Assessment	o Yesá o No	o Yesá o No

2. Requirements for Test

The listing below identifies those items╛use cases, functional requirements, and non-functional requirements╛that have been identified as targets for testing.á This list represents what will be tested.á

[Enter a high level list of the major test requirements.]

3. Test Strategy

[The Test Strategy presents the recommended approach to the testing of the target-of-test.á The previous section, Requirements for Test, described what will be tested╛this describes how the target-of-test will be tested.á

For each type of test, provide a description of the test and why it is being implemented and executed.

If a type of test will not be implemented and executed, indicate this in a sentence stating the test will not be implemented or executed and stating the justification, such as ôThis test will not be implemented or executed.á This test is not appropriate.ö

The main considerations for the test strategy are the techniques to be used and the criterion for knowing when the testing is completed.

In addition to the considerations provided for each test below, testing should only be executed using known, controlled databases in secured environments. ]

3.1 Testing Types

3.1.1 Data and Database Integrity Testing

[The databases and the database processes should be tested as a subsystem within the <Project Name>. These subsystems should be tested without the target-of-testÆs User Interface as the interface to the data.á Additional research into the DataBase Management System (DBMS) needs to be performed to identify the tools and techniques that may exist to support the testing identified below.]

Test Objective:	[Ensure database access methods and processes function properly and without data corruption.]
Technique:	╖áááá [Invoke each database access method and process, seeding each with áááááááááááá valid and invalid data or requests for data. ╖áá áInspect the database to ensure the data has been populated as ááááá intended, all database events occurred properly, or review the ááááá returned data to ensure that the correct data was retrieved for the ááááá correct reasons]
Completion Criteria:	[All database access methods and processes function as designed and without any data corruption.]
Special Considerations:	╖áá á[Testing may require a DBMS development environment or drivers to ááááá enter or modify data directly in the databases. ╖ááá Processes should be invoked manually. ╖áá Small or minimally sized databases (limited number of records) should áááááááá be used to increase the visibility of any non-acceptable events.]

3.1.2 Function Testing

[Function testing of the target-of-test should focus on any requirements for test that can be traced directly to use cases or business functions and business rules.á The goals of these tests are to verify proper data acceptance, processing, and retrieval, and the appropriate implementation of the business rules.á This type of testing is based upon black box techniques; that is verifying the application and its internal processes by interacting with the application via the Graphical User Interface (GUI) and analyzing the output or results.á Identified below is an outline of the testing recommended for each application:]

Test Objective:	[Ensure proper target-of-test functionality, including navigation, data entry, processing, and retrieval.]
Technique:	[Execute each use case, use-case flow, or function, using valid and invalid data, to verify the following: ╖ááá The expected results occur when valid data is used. ╖ááá The appropriate error or warning messages are displayed when ááááá invalid data is used. ╖á á Each business rule is properly applied.]
Completion Criteria:	╖áá [All planned tests have been executed. ╖á á áAll identified defects have been addressed.]
Special Considerations:	[Identify or describe those items or issues (internal or external) that impact the implementation and execution of function test]

3.1.3 Business Cycle Testing

[Business Cycle Testing should emulate the activities performed on the <Project Name> over time.á A period should be identified, such as one year, and transactions and activities that would occur during a yearÆs period should be executed.á This includes all daily, weekly, and monthly cycles and, events that are date-sensitive, such as ticklers.]

Test Objective	[Ensure proper target-of-test and background processes function according to required business models and schedules.]
Technique:	[Testing will simulate several business cycles by performing the following: ╖áá The tests used for target-of-testÆs function testing will be modified or ááááá enhanced to increase the number of times each function is executed to ááááá simulate several different users over a specified period. ╖á á All time or date-sensitive functions will be executed using valid and ááááá invalid dates or time periods. ╖áá All functions that occur on a periodic schedule will be executed or ááááá launched at the appropriate time. ╖áá Testing will include using valid and invalid data to verify the ááááá following: ╖áá The expected results occur when valid data is used. ╖á á áThe appropriate error or warning messages are displayed when ááááá invalid data is used. ╖á á áEach business rule is properly applied.
Completion Criteria:	╖á á á[All planned tests have been executed. ╖áá All identified defects have been addressed.}
Special Considerations:	╖áá [System dates and events may require special support activities ╖áá Business model is required to identify appropriate test requirements ááááá and procedures.]

3.1.4 User Interface Testing

[User Interface (UI) testing verifies a userÆs interaction with the software.á The goal of UI testing is to ensure that the User Interface provides the user with the appropriate access and navigation through the functions of the target-of-test.á In addition, UI testing ensures that the objects within the UI function as expected and conform to corporate or industry standards.]

Test Objective:	[Verify the following: ╖áá Navigation through the target-of-test properly reflects business ááááá functions and requirements, including window-to-window, field-to- ááááá field, and use of access methods (tab keys, mouse movements, ááááá accelerator keys) ╖á á Window objects and characteristics, such as menus, size, position, ááááá state, and focus conform to standards.]
Technique:	[Create or modify tests for each window to verify proper navigation and object states for each application window and objects.]
Completion Criteria:	[Each window successfully verified to remain consistent with benchmark version or within acceptable standard]
Special Considerations:	[Not all properties for custom and third party objects can be accessed.]

3.1.5 Performance Profiling

[Performance profiling is a performance test in which response times, transaction rates, and other time-sensitive requirements are measured and evaluated.á The goal of Performance Profiling is to verify performance requirements have been achieved. Performance profiling is implemented and executed to profile and tune a target-of-test's performance behaviors as a function of conditions such as workload or hardware configurations.

Note:á Transactions below refer to ôlogical business transactionsö.á These transactions are defined as specific use cases that an actor of the system is expected to perform using the target-of-test, such as add or modify a given contract.]

Test Objective:	[Verify performance behaviors for designated transactions or business functions under the followingá conditions: ╖ááá normal anticipated workload ╖ááá anticipated worst case workload]
Technique:	╖ááá [Use Test Procedures developed for Function or Business Cycle ááááá Testing. ╖ááá Modify data files to increase the number of transactions or the scripts ááááá to increase the number of iterations each transaction occurs. ╖ááá Scripts should be run on one machine (best case to benchmark single ááááá user, single transaction) and be repeated with multiple clients (virtual áááááá or actual, see Special Considerations below).]
Completion Criteria:	╖ááá [Single Transaction or single user:á Successful completion of the test ááááá scripts without any failures and within the expected or required time ááááá allocation per transaction.] ╖ááá [Multiple transactions or multiple users:á Successful completion of the áááááááááááááá test scripts without any failures and within acceptable time ááááá allocation.]
Special Considerations:	[Comprehensive performance testing includes having a background workload on the server.á There are several methods that can be used to perform this, including:á ╖áá ôDrive transactionsö directly to the server, usually in the form of ááááá Structured Query Language (SQL) calls. ╖ááá Create ôvirtualö user load to simulate many clients, usually several ááááá hundred.á Remote Terminal Emulation tools are used to accomplish ááááá this load.á This technique can also be used to load the network with ááááá ôtrafficö. ╖ááá Use multiple physical clients, each running test scripts to place a load áááááááááááá on the system.á Performance testing should be performed on a dedicated machine or at a dedicated time.á This permits full control and accurate measurement. The databases used for Performance Testing should be either actual size or scaled equally.]

3.1.6 Load Testing

[Load testing is a performance test which subjects the target-of-test to varying workloads to measure and evaluate the performance behaviors and ability of the target-of-test to continue to function properly under these different workloads.áá The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload.á Additionally, load testing evaluates the performance characteristics, such as response times, transaction rates, and other time sensitive issues).]

[Note:á Transactions below refer to ôlogical business transactionsö.áá These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract.]

Test Objective:	[Verify performance behavior time for designated transactions or business cases under varying workload conditions.]
Technique:	╖ááá [Use tests developed for Function or Business Cycle Testing. ╖ááá Modify data files to increase the number of transactions or the tests to ááááá increase the number of times each transaction occurs.]
Completion Criteria:	[Multiple transactions or multiple users:á Successful completion of the tests without any failures and within acceptable time allocation.]
Special Considerations:	╖ááá [Load testing should be performed on a dedicated machine or at a ááááá dedicated time.á This permits full control and accurate measurement. ╖ááá The databases used for load testing should be either actual size or ááááá scaled equally.]

3.1.7 Stress Testing

[Stress testing is a type of performance test implemented and executed to find errors due to low resources or competition for resources. Low memory or disk space may reveal defects in the target-of-test that aren't apparent under normal conditions. Other defects might result from competition for shared resources like database locks or network bandwidth. Stress testing can also be used to identify the peak workload the target-of-test can handle.]

[Note:á References to transactions below refer to logical business transactions.]

Test Objective:	[Verify that the target-of-test functions properly and without error under the following stress conditions: ╖ááá little or no memory available on the server (RAM and DASD) ╖ááá maximum actual or physically capable number of clients connected or simulated ╖ááá multiple users performing the same transactions against the same data áááááááááááá or accounts ╖ááá worst case transaction volume or mix (see Performance Testing ááááá above). Notes:á ááááááá The goal of Stress Testing might also be stated as identify and ááááááááááááááááááááááááááááá document the conditions under which the system FAILS toáááááááááááááááááááááá áááááááááááááááááááááááááááááá continue functioning properly. ááááááááááááááááááááá Stress Testing of the client is described under section 3.1.11, ááááááááááááááááááááá Configuration Testing.]
Technique:	╖ááá [Use tests developed for Performance Profiling or Load Testing. ╖ááá To test limited resources, tests should be run on a single machine, and ááááá RAM and DASD on server should be reduced or limited. ╖ááá For remaining stress tests, multiple clients should be used, either ááááá running the same tests or complementary tests to produce the worst ááááá case transaction volume or mix.
Completion Criteria:	[All planned tests are executed and specified system limits are reached or exceeded without the software failing or conditions under which system failure occurs is outside of the specified conditions.]
Special Considerations:	╖ááá [Stressing the network may require network tools to load the network ááááá with messages or packets. ╖ááá The DASD used for the system should temporarily be reduced to ááááá restrict the available space for the database to grow. ╖ááá Synchronization of the simultaneous clients accessing of the same ááááá records or data accounts.]

3.1.8 Volume Testing

[Volume Testing subjects the target-of-test to large amounts of data to determine if limits are reached that cause the software to fail.á Volume Testing also identifies the continuous maximum load or volume the target-of-test can handle for a given period.á For example, if the target-of-test is processing a set of database records to generate a report, a Volume Test would use a large test database and check that the software behaved normally and produced the correct report.]

Test Objective:	[Verify that the target-of-test successfully functions under the following high volume scenarios: ╖ááá Maximum (actual or physically- capable) number of clients connected, or simulated, all performing the same, worst case (performance) áááááááááá business function for an extended period. ╖ááá Maximum database size has been reached (actual or scaled) and ááááá multiple ááááááááááááááá queries or report transactions are executed simultaneously.]
Technique:	╖ááá [Use tests developed for Performance Profiling or Load Testing. ╖ááá Multiple clients should be used, either running the same tests or ááááá complementary tests to produce the worst case transaction volume or ááááá mix (see Stress Testing above) for an extended period. ╖ááá Maximum database size is created (actual, scaled, or filled with ááááá representative data) and multiple clients used to run queries and ááááá report transactions simultaneously for extended periods.]
Completion Criteria:	╖ááá [All planned tests have been executed and specified system limits are ááááá reached or exceeded without the software or software failing.]
Special Considerations:	[What period of time would be considered an acceptable time for high volume conditions, as noted above?]

3.1.9 Security and Access Control Testing

[Security and Access Control Testing focus on two key areas of security:á

╖ááááá Application-level security, including access to the Data or Business Functions

╖ááá System-level Security, including logging into or remote access to the system.

Application-level security ensures that, based upon the desired security, actors are restricted to specific functions or use cases, or are limited in the data that is available to them.á For example, everyone may be permitted to enter data and create new accounts, but only managers can delete them.á If there is security at the data level, testing ensures thatö user type oneö can see all customer information, including financial data, however,ö user twoö only sees the demographic data for the same client.

System-level security ensures that only those users granted access to the system are capable of accessing the applications and only through the appropriate gateways.]

Test Objective:	╖ Application-level Security:á [Verify that an actor can access only those functions or data for which their user type is provided permissions.] ╖ System-level Security:á Verify that only those actors with access to the system and applications are permitted to access them.]
Technique:	╖ Application-level Security:á [Identify and list each user type and the functions or data each type has permissions for.] ╖ááá [Create tests for each user type and verify each permission by creating transactions specific to each user type.] ╖ááá Modify user type and re-run tests for same users.á In each case, verify those additional functions or data are correctly available or denied. ╖ System-level Access: [See Special Considerations below]
Completion Criteria:	[For each known actor type the appropriate function or data are available, and all transactions function as expected and run in prior Application Function tests.]á
Special Considerations:	[Access to the system must be reviewed or discussed with the appropriate network or systems administrator.á This testing may not be required as it may be a function of network or systems administration.]

3.1.10 Failover and Recovery Testing

[Failover and RecoveryTesting ensures that the target-of-test can successfully failover and recover from a variety of hardware, software or network malfunctions with undue loss of data or data integrity.á

Failover testing ensures that, for those systems that must be kept running, when a failover condition occurs, the alternate or backup systems properly ôtake overö for the failed system without loss of data or transactions.

Recovery testing is an antagonistic test process in which the application or system is exposed to extreme conditions, or simulated conditions, to cause a failure, such as device Input/Output (I/O) failures or invalid database pointers andá keys.á Recovery processes are invoked and the application or system is monitored and inspected to verify proper application, orá system,á and data recovery has been achieved.]

Test Objective:	[Verify that recovery processes (manual or automated) properly restore the database, applications, and system to a desired, known, state.á The following types of conditions are to be included in the testing: ╖ááá power interruption to the client ╖ááá power interruption to the server ╖ááá communication interruption via network servers ╖ááá interruption, communication, or power loss to DASD and or ááááá DASD controllers ╖ááá incomplete cycles (data filter processes interrupted, data ááááá synchronization processes interrupted). ╖ááá invalid database pointer or keys ╖ááá invalid or corrupted data element in database]
Technique:	[Tests created for Function and Business Cycle testing should be used to create a series of transactions.á Once the desired starting test point is reached, the following actions should be performed, or simulated, individually: ╖ááá Power interruption to the client:á power the PC down. ╖ááá Power interruption to the server: simulate or initiate power ááááá down procedures for the server. ╖ááá Interruption via network servers:á simulate or initiate ááááá communication loss with the network (physically disconnect ááááá communication wires or power down network servers or ááááá routers. ╖ááá Interruption, communication, or power loss to DASD and ááááá DASD controllers: simulate or physically eliminate ááááá communication with one or more DASD controllers or ááááá devices. Once the above conditions or simulated conditions are achieved, additional transactions should be executed and upon reaching this second test point state, recovery procedures should be invoked. Testing for incomplete cycles utilizes the same technique as described above except that the database processes themselves should be aborted or prematurely terminated. Testing for the following conditions requires that a known database state be achieved.á Several database fields, pointers, and keys should be corrupted manually and directly within the database (via database tools).á Additional transactions should be executed using the tests from Application Function and Business Cycle Testing and full cycles executed.]
Completion Criteria:	[In all cases above, the application, database, and system should, upon completion of recovery procedures, return to a known, desirable state.á This state includes data corruption limited to the known corrupted fields, pointers or keys, and reports indicating the processes or transactions that were not completed due to interruptions.]
Special Considerations:	╖ááá [Recovery testing is highly intrusive.á Procedures to ááááá disconnect cabling (simulating power or communication loss) ááááááááááá may not be desirable or feasible.á Alternative methods, such ááááááááááá as diagnostic software tools may be required. ╖ááá Resources from the Systems (or Computer Operations), ááááá Database, and Networking groups are required. ╖ááá These tests should be run after hours or on an isolated ááááá machine.]

3.1.11 Configuration Testing

[Configuration testing verifies the operation of the target-of-test on different software and hardware configurations.á In most production environments, the particular hardware specifications for the client workstations, network connections and database servers vary.á Client workstations may have different software loaded╛for example, applications, drivers, etc.╛and at any one time, many different combinations may be active using different resources.]

Test Objective:	[Verify that the target-of-test functions properly on the required hardware and software configurations.]
Technique:	╖ááá [Use Function Test scripts. ╖ááá Open and close various non-target-of-test related software, ááááá such as the Microsoft applications, Excel and Word, either as part of the test or prior to the start of the test. ╖ááá Execute selected transactions to simulate actorÆs interacting ááááá with the target-of-test and the non-target-of-test software. ╖ááá Repeat the above process, minimizing the available ááááá conventional memory on the client workstation.]
Completion Criteria:	[For each combination of the target-of-test and non-target-of-test software, all transactions are successfully completed without failure.]
Special Considerations:	╖ááá [What non-target-of-test software is needed, is available, and ááááá is accessible on the desktop? ╖ááá What applications are typically used? ╖ááá What data are the applications running; for example, a large ááááá spreadsheet opened in Excel or a 100- page document in ááááá Word? ╖ááá The entire systems, netware, network servers, databases, etc. ááááá should also be documented as part of this test.]á

3.1.12 Installation Testing

[Installation testing has two purposes. The first is to insure that the software can be installed under different conditions╛such as a new installation, an upgrade, and a complete or custom installation╛under normal and abnormal conditions. Abnormal conditions include insufficient disk space, lack of privilege to create directories, etc. The second purpose is to verify that, once installed, the software operates correctly. This usually means running a number of the tests that were developed for Function Testing.]

Test Objective:	Verify that the target-of-test properly installs onto each required hardware configuration under the following conditions: ╖ááá new installation, a new machine, never installed previously ááááá with <Project Name> ╖ááá update,á machine previously installed <Project Name>, same ááááá version ╖ááá update,á machine previously installed <Project Name>, older áááááááááá version á
Technique:	╖ááá [Manually or develop automated scripts, to validate the ááááá condition of the target machine╛ new - <Project Name>ááááá never installed; <Project Name> same version or older ááááá version already installed). ╖ááá Launch or perform installation. ╖ááá Using a predetermined sub-set of function test scripts, run the áááááááááááááá transactions.]
Completion Criteria:	<Project Name> transactions execute successfully without failure.
Special Considerations:	[What <Project Name> transactions should be selected to comprise a confidence test that <Project Name> application has been successfully installed and no major software components are missing?]

3.2 Tools

The following tools will be employed for this project:

[Note:á Delete or add items as appropriate.]

	Tool	Vendor/In-house	Version
Test Management
Defect Tracking
ASQ Tool for functional testing
ASQ Tool for performance testing
Test Coverage Monitor or Profiler
Project Management
DBMS tools

4. Resources

[This section presents the recommended resources for the <Project Name> project, their main responsibilities, and their knowledge or skill set.]

4.1 Workers

This table shows the staffing assumptions for the project.

[NOTE:á Delete or add items as appropriate.]

Human Resources
Worker	Minimum Resources Recommended (number of full-time workers allocated)	Specific Responsibilities or Comments
Test Manager, Test Project Manager		Provides management oversight. Responsibilities: ╖ provide technical direction ╖ acquire appropriate resources ╖ provide management reporting
Test Designer		Identifies, prioritizes, and implements test cases. Responsibilities: ╖ generate test plan ╖ generate test model ╖ evaluate effectiveness of test effort
Tester		Executes the tests. Responsibilities: ╖ execute tests ╖ log results ╖ recover from errors ╖ document change requests
Test System Administrator		Ensures test environment and assets are managed and maintained. Responsibilities: ╖ administer test management system ╖ install and manage worker access to test systems
Database Administratator, Database Manager		Ensures test data (database) environment and assets are managed and maintained. Responsibilities: ╖ administer test data (database)
Designer		Identifies and defines the operations, attributes, and associations of the test classes. Responsibilities: ╖ identifies and defines the test class(es) ╖ identifies and defines the test packages
Implementer		Implements and unit tests the test classes and test packages. Responsibilities: ╖ creates the test classes and packages implemented in the test model

4.2 System

The following table sets forth the system resources for the testing project.

[The specific elements of the test system are not fully known at this time.á It is recommended that the system simulate the production environment, scaling down the accesses and database sizes if and where appropriate.]

[Note:á Delete or add items as appropriate.]

System Resources
Resource	Name / Type
Database Server
ùNetwork or Subnet	TBD
ùServer Name	TBD
ùDatabase Name	TBD
Client Test PC's
ùInclude special configuration requirements	TBD
Test Repository
ùNetwork or Subnet	TBD
ùServer Name	TBD
Test Development PC's	TBD

5. Project Milestones

[Testing of <Project Name> should incorporate test activities for each of the test efforts identified in the previous sections.á Separate project milestones should be identified to communicate project status accomplishments.]

Milestone Task	Effort	Start Date	End Date
Plan Test
Design Test
Implement Test
Execute Test
Evaluate Test

6. Deliverables

[In this section list the various documents, tools, and reports that will be created, by whom, delivered to who, and when delivered.]

7. Appendix A: Project Tasks

Below are the test related tasks:

╖ááááááá Plan Test

- identify requirements for test

- assess risk

- develop test strategy

- identify test resources

- create schedule

- generate Test Plan

╖ááááááá Design Test

-áááááá prepare workload analysis

-áááááá identify and describe test cases

-áááááá identify and structure test procedures

ááááááááá -áááááá review and assess test coverageá

╖ááááááá Implement Test

- record or program test scripts

- identify test-specific functionality in the Design and Implementation Model

- establish external data sets

╖ááááááá Execute Test

ááááááááá -áááááá execute Test procedures

ááááááááá -ááááááááá evaluate execution of Test

ááááááááá -áááááá recover from halted Test

ááááááááá -áááááá verify the results

ááááááááá -ááááááááá investigate unexpected results

ááááááááá -áááááá log defects

╖ááááááá Evaluate Test

ááááááááá -ááááááááá evaluate Test-case coverage

ááááááááá -ááááááááá evaluate code coverage

ááááááááá -áááááá analyze defects

ááááááááá -ááááááááá determine if Test Completion Criteria and Success Criteria have been achieved

ááááááááá

1. Introduction

1.1 Purpose

1.2 Background

1.3 Scope

1.4 Project Identification

2. Requirements for Test

3. Test Strategy

3.1 Testing Types

3.1.1 Data and Database Integrity Testing

3.1.2 Function Testing

3.1.3 Business Cycle Testing

3.1.4 User Interface Testing

3.1.5 Performance Profiling

3.1.6 Load Testing

3.1.7 Stress Testing

3.1.8 Volume Testing

3.1.9 Security and Access Control Testing

3.1.10 Failover and Recovery Testing

3.1.11 Configuration Testing

3.1.12 Installation Testing

3.2 Tools

4. Resources

4.1 Workers

4.2 System

5. Project Milestones

6. Deliverables

6.1 Test Model

6.2 áTest Logs

6.3 Defect Reports

7. Appendix A: Project Tasks